To improve data transmission security over computer networks and to prevent digital forgery, a digital signature is commonly used to authenticate a file i.e., to check file integrity and to authenticate signer. Such digital signature allows, for example, to control the source of a received file, and to verify the file integrity. A digital signature asserts that the user corresponding to the digital signature wrote or otherwise agreed with the contents of an electronic document or other information object to which the digital signature is appended. As with written signatures, digital signatures provide authentication of the signer's identity, acceptance of the terms stated in the signed document, proof of the integrity of the document's contents, and non repudiation (in other words, the signer cannot deny what he/she has signed). Digital signatures are generally based upon public key algorithms wherein security is provided through keys independently of the used algorithm, which may be freely published or analyzed.
A digital certificate can be considered as an attachment to a signed document, to link the identity of the signer of the document to his/her public key. A digital certificate provides a cryptographic public key that allows another party to encrypt information for the certificate's owner. A digital certificate also allows to verify that a user sending a document is who he/she claims to be, and to provide the receiver with the means to encode a reply. A certificate therefore securely identifies the owner of the public key pair, which is used to provide authentication, authorization, encryption, and non-repudiation services. A digital certificate contains the signer's public key and bears, the digital signature of a Certification Authority (CA). The most widely used standard for digital certificates is X.509, Version 3, “The Directory-Authentication Framework 1988”, promulgated by the International Telecommunications Union (ITU), which defines the following structure for public-key certificates:                version field (identifying the certificate format)        Serial Number (unique within the CA)        Signature Algorithm (identifying the issuer's hash and digital signature algorithms used to sign the certificate)        Issuer Name (the name of the CA)        Period of Validity (a pair of “Not Before”, and “Not After” Dates)        Subject Name (the name of the user to whom the certificate is issued)        Subject's Public Key field (including Algorithm name and the Public Key of the subject)        Extensions        Signature of CA        
A certification authority is the third party that everyone trusts whose responsibility is to issue digital certificates providing the link between the signer and the signer's public key. A certification authority (CA) also keeps records about the transactions that occur using certificates it has issued. An individual wishing to sign a document applies for a digital certificate from a Certification Authority. The digital certificate is digitally signed by the issuing Certification Authority that ensures both content and source integrity. The CA makes its own public key readily available through, for example, print publicity or on the Internet. The act of digitally signing makes the certificates substantially tamperproof, and therefore further protection is not needed. The strength of protection equates directly to the strength of the algorithm and key size used in creating the issuer's digital signature (hash and digital signature algorithms).
The signature verification process checks the digital signature appended or attached to a document using the public verification key extracted from the digital certificate, issued by the CA, that must be also appended to or referenced in the document. Using the public key of the signer, the signature verification process recovers from the digital signature, the hash value, computed by the signer, in the file that was signed using the private key of the signer during the authentication process. To verify that the file is authentic, the receiver computes also the hash value of the document, and then compares the deciphered hash value with the real hash value, computed from the file. If both hash values are identical, the file is accepted as authentic, otherwise, the file is rejected as being corrupted or fake.
Once the digital signature of a file has been computed and the file has been signed with the digital signature for verification purposes, a digital certificate must be associated with the signed file to make possible the verification of the digital signature by the recipient.
Generally, a digital certificate used for authenticating a file is transmitted as a separate file, appended to the file it authenticates e.g., as part of a file wrapper structure, or alternatively, the certificate can be retrieved from a reference or address e.g., the URL of the certificate on the issuing CA Web Server.
Transmitting and maintaining digital certificates and signed documents as separate files e.g., the digital certificate associated to a signed document is stored in the user's workstation or in a server, presents the advantage of supporting file authentication at any time in a simple and well understood way. However, if documents are later passed on or moved to new recipients, associated digital certificates can be lost, accidentally removed, or even intentionally removed on the way in an attempt to cheat.
Wrapping a file with delimiters and appending the digital certificate, or the URL of said certificate on the issuing CA Web Server, at the end of the signed file is convenient, since both the certificate, or the certificate address, and the signed content travel together. Conversely, the wrapper and the certificate, or the certificate address, will typically need to be removed before the file can be used. Thus, signature validation only occurs when the document is retrieved. If the document is later passed on or moved, it may be difficult to check again, since the certificate, or the certificate address, could be lost. Furthermore, the method is not compatible with standard file formats such as image, video, audio or executable files that cannot be recognized prior to authentication.
When a recipient receives an electronic document, if the digital certificate has been appended to the signed document, the recipient must perform the following tasks:                open the electronic document;        identify and extract, from the electronic document, the digital certificate and the digital signature portions appended to this electronic document;        identify the address and contact the CA to check that the appended certificate is a valid certificate, using the digital certificate content; and,        verify the signature using the public key in the certificate.        
It must be observed that if the digital certificate is appended to the received electronic document, the recipient must open the document file for accessing the digital certificate required to verify the signature. Even when the certificate, instead of being appended, would be referenced e.g., as a network address or URL, in the received document, the address from which the certificate e.g., from a CA Web Server or directory archive, can be accessed or retrieved, must also be appended by the sender to the signed document. Therefore, it is also required to open the received document to get said address needed for accessing the digital certificate.
Thus, there are security problems related to the methods described above for verifying the authenticity of received or accessed files by the recipient:                when certificates are sent as separate files, the associated digital certificates could be lost if the signed files are later passed on or moved to new recipients. In such case, it is impossible to verify these signed files.        when certificates, or certificates addresses, are appended to the signed files, recipients must open and process the received files to verify said files. Before opening a received files, parsing the content for locating, and retrieving, or accessing, the associated certificate, there is no way to determine in advance, whether the received file has been signed or not i.e., whether it is an “authenticated” file or an “impersonated” file (a non-signed file). Likewise, it is impossible to determine whether or not the certificate is valid i.e., if it has been issued by a CA, if it has not been revoked, and if the certificate date is valid.        
It is also to be noticed that opening files for verification represents an important security concern.
Many viruses spread on the Internet on e-mail attachments distributed as “impersonated”. If a received impersonated file has been maliciously infected by a virus, opening the infected file for the simple purpose of signature verification almost surely may “open” the door for infecting the receiver's computer. This is a “security hole” common to all signature methods described above, as illustrated by operation of the class of public-key algorithms discussed herein before.
Certificates must be issued by certificate authorities. If a certificate becomes compromised, the certificate authority can later revoke the certificate, thus rendering invalid all files signed after the signature's revocation date. A certificate could become compromised if an unauthorized third-party obtained the private key associated with the certificate. This private key is typically stored on the signer's computer. With the private key, an unauthorized person could essentially forge a signature. If the recipient receives a file signed with a revoked certificate, it is must be discarded as invalid or fake.
Therefore, before opening a received file, it would be advisable to check:                if the file has been signed i.e., if it contains a digital signature and a digital certificate appended or referenced;        the issuer name i.e., the name of the CA;        the name of the user to whom the certificate has been issued; and,        the validity period of the certificate.        
Therefore, there is a need to provide a method and systems for accessing a digital certificate from a signed file before opening said file, so as to enable the recipient of the file to determine if the received file has been signed i.e., authenticated, and to check the identify of signer e.g., contacting the signer by e-mail, and the validity of the digital certificate before opening said file for signature verification.